-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: document use of the Squash and merge button #11686
Conversation
The `Create a Merge Commit` and `Rebase and Merge` buttons are not currently suitable for merging Pull Requests, and are thus disabled. Squashing is okay, so we should document its use. Fixes: nodejs#11674
If the consensus is that the |
button, as long as you: | ||
* Remove the PR number, e.g. `(#1048)`, from the commit message title. | ||
* Ensure that the commit message is correct, remove any fixup commit messages. | ||
* Make sure CI was run on the latest update to the Pull Request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this something specific to using the button?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@seishun in a certain sense it is as you shouldn't press the button without making sure that CI is passing. I would keep it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lpinca you should also not press the button until someone has reviewed the PR. Should this be mentioned here too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think not, that is already known by collaborators and is part of the on-boarding process. You can argue that landing a PR after ensuring that CI is passing is also part of the on-boarding process but I would still keep this sentence as it doesn't harm and is not off-topic.
This is just my opinion though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@seishun also that is "included" in the next line:
Add the correct metadata (see below).
That means that PR must be reviewed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to give a complete list, as I assumed someone using the button to make life easier wouldn't necessarily want to read through the command line instructions to work out which rules still applied.
["Squash and merge"](https://help.github.com/articles/about-pull-request-merges/#squash-and-merge-your-pull-request-commits) | ||
button, as long as you: | ||
* Remove the PR number, e.g. `(#1048)`, from the commit message title. | ||
* Ensure that the commit message is correct, remove any fixup commit messages. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps just say that the commit message needs to be updated to conform to the contributions guidelines?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree.
Following @bnoordhuis's comment (#11674 (comment)), if we want to be strict about the committer field, then we should document that the "Squash and merge" button can only be used to merge others' PRs. |
We should encourage people to not fully squash when it would make more sense to keep some separate commits though. I'm still in favor of never using it because then at least everyone always gets taught how to do it and has full control each time. |
I'm fine either way, but in this case we should disable the button altogether. |
Ok then I think it doesn't make sense to have the merge buttons enabled. We can disable all of them and update this PR to completely remove the section about the merge button. |
+1 to disabling the button if we're not using it, but I don't think we should remove the section altogether, as I recall @Trott's original reason for adding it was that "why can't we use it" is a question that got asked at every onboarding. I can update this PR to update the reasons though (as @seishun says, the current reasons aren't very accurate). |
I guess the question is asked after the collaborator is instructed to never use the button. If there is no button there is no need to tell the collaborator to not use it and also probably no question, but I agree that it is still useful to know why it is disabled. |
I would support completely disabling the button despite the fact that it has some use, simply to prevent someone from using it incorrectly through accident or ignorance. But if we can't disable it completely, then I don't think we should prohibit its usage. Instead, we should explain why it should be avoided and let the collaborators decide for themselves. |
Have we agreed on whether we can use the button or not? 🤔 |
Ping @nodejs/ctc ... please take a moment to review this issue. |
Per #11686 (comment), it would be an if a then b else c kind of rule, which is easier to get wrong than our current don't do b rule. -1 on changing it. |
To summarize, the issues with the
We currently can't disable it, as you can only disable two of the three merge options (and we should probably choose to disable
I don't think we want to get into the situation where it's officially forbidden or discouraged, but some people use it. If there was a browser extension that did what |
@gibfahn Should this PR be closed? Updated? Something else? |
@gibfahn I think another issue with it is it may encourage new contributors to squash commits that should be kept separate? |
@Trott I think this can be closed, given feedback. However I think someone with access should probably disable the @silverwind if you still think the justification for not using the buttons should be updated, feel free. |
Closing given the status of the conversation. Will bring up disabling the |
Since it's so easy to undo, something that no one uses, and something that we don't want people to use, how about do it and leave a comment here @-mentioning CTC letting them know it happened and to comment if they have concerns. (Then we can focus on the Buffer thing at the CTC meeting, which feels like it could easily take the whole hour by itself...) |
I've set it to 'Allow merge commits' for now. |
@gibfahn Any chance you meant to say leave "Allow rebase commits" enabled but instead disable "Allow merge commits"? I think the former is less problematic than the latter, but maybe there's something I'm missing? |
'Allow merge commits' seems logical to me. There can be no confusion whether it's okay to use the green button now because we never use merge commits; with the squash & rebase option it's less clear cut. |
@nodejs/ctc The settings on the site have been updated (thanks @bnoordhuis) to disable the "Allow rebase commits" option. The reasoning is above. If you have any questions or concerns, comment here. Thanks! |
I guess the guide needs to explain why they are disabled then. |
The
Create a Merge Commit
andRebase and Merge
buttons are notcurrently suitable for merging Pull Requests, and are thus disabled.
Squashing is okay, so we should document its use.
Fixes: #11674
Checklist
Affected core subsystem(s)
doc
cc/ @seishun @MylesBorins @evanlucas @mscdex @lpinca